MCP 클라이언트는 여러분의 서버와 MCP 서버 간의 통신 다리 역할을 합니다. MCP 서버가 제공하는 모든 도구에 접근하는 창구라고 생각하세요. 외부 도구나 서비스를 사용해야 할 때, 클라이언트가 모든 메시지 전달 및 프로토콜 세부 사항을 처리해 줍니다.

전송 방식에 독립적인 통신

MCP의 주요 강점 중 하나는 전송 방식에 독립적이라는 점입니다. 이는 클라이언트와 서버가 서로 다른 통신 방법으로 대화할 수 있다는 것을 의미합니다. 가장 일반적인 설정은 MCP 클라이언트와 서버를 같은 머신에서 실행하며, 표준 입력/출력을 통해 통신합니다.

하지만 그 방식에만 국한되지 않습니다. MCP 클라이언트와 서버는 다음을 통해서도 연결할 수 있습니다:

• HTTP
• WebSockets
• 기타 다양한 네트워크 프로토콜

메시지 유형

연결되면 클라이언트와 서버는 MCP 명세에 정의된 특정 메시지 유형을 교환합니다. 주로 다루게 될 메시지 유형은 다음과 같습니다:

ListToolsRequest/ListToolsResult: 클라이언트가 서버에 "어떤 도구를 제공하나요?"라고 묻고, 사용 가능한 도구 목록을 돌려받습니다.

CallToolRequest/CallToolResult: 클라이언트가 서버에 특정 인수로 특정 도구를 실행하도록 요청하고, 결과를 받습니다.

전체 흐름 예시

실제 시나리오에서 모든 구성 요소가 어떻게 함께 동작하는지 살펴보겠습니다. 사용자가 "내 저장소가 어떤 것들이 있나요?"라고 묻는다고 가정하면, 전체 통신 흐름은 다음과 같습니다:

사용자가 여러분의 서버에 쿼리를 제출하면 프로세스가 시작됩니다. 서버는 요청을 하기 전에 Claude에게 사용 가능한 도구 목록을 제공해야 한다는 것을 인식합니다.

서버는 MCP 클라이언트에 도구 목록을 요청하고, 클라이언트는 MCP 서버에 ListToolsRequest를 보내 ListToolsResult를 받습니다.

이제 서버는 Claude에 초기 요청을 하기 위한 모든 것, 즉 사용자의 질문과 사용 가능한 도구 목록을 갖추게 됩니다.

Claude는 도구 목록을 검토하고 질문에 답하기 위해 하나를 호출해야 한다고 결정합니다. 도구 사용 요청으로 응답합니다.

서버는 MCP 클라이언트에 Claude가 요청한 도구를 실행하도록 요청합니다. MCP 클라이언트는 MCP 서버에 CallToolRequest를 보내고, MCP 서버는 GitHub에 실제 요청을 합니다.

GitHub이 저장소 데이터를 반환하면, 이 데이터는 MCP 서버를 통해 CallToolResult로, 다시 MCP 클라이언트를 통해, 마지막으로 여러분의 서버로 전달됩니다.

서버는 도구 결과를 후속 메시지로 Claude에 다시 보냅니다. Claude는 이제 완전한 응답을 구성하는 데 필요한 모든 정보를 갖추게 됩니다.

마지막으로, Claude는 형식화된 답변으로 응답하고, 서버는 이를 사용자에게 전달합니다.

네, 이 흐름은 많은 단계를 포함하지만, 각 구성 요소는 명확한 책임을 가지고 있습니다. MCP 클라이언트는 서버 통신의 복잡성을 추상화하여, 여러분이 애플리케이션 로직 구축에 집중할 수 있게 해줍니다. 자체 MCP 클라이언트와 서버를 구현하면서 각 구성 요소가 실제로 어떻게 맞물리는지 확인하게 될 것입니다.